AWS Glue 実践入門 環境準備編(2)：データストアアクセス・開発エンドポイント設定について

AWS Glueのサービスを本格活用するには、事前に幾つかの準備作業が必要となります。下記エントリで「IAM権限周り」に関する設定を行いましたが、当エントリではその続きとなる「データストアアクセス・開発エンドポイント設定」について見ていきたいと思います。

• Setting Up Your Environment to Access Data Stores - AWS Glue
• AWS Glue実践入門 ｜ シリーズ ｜ Developers.IO

目次

• Amazon S3アクセス用にVPCエンドポイントを作成
  • VPC及びサブネットの作成
  • VPCエンドポイントの作成
• JDBCデータストアに対する接続設定(自己参照ルールを持つセキュリティグループの作成・設定)
• VPCのDNS設定
• 開発エンドポイント用の環境設定
• ここまでの手順でで出来上がった要素
• まとめ

Amazon S3アクセス用にVPCエンドポイントを作成

AWS GlueからS3のアクセスに関しては「VPCエンドポイント」を利用する事でより安全な形でデータの送受信を行わせる事が出来ます。VPCエンドポイントを使う事でAWS GlueはプライベートIPを使用してパブリックなインターネット通信にさらされる事無くAmazon S3にアクセス出来るようになります。

VPC及びサブネットの作成

とその前に、今回の検証で用いるVPCエンドポイントを作成するための対象となるVPC及びサブネットを新たに作成しましょう。今回はCloudFormationを使ってこの部分をサクッと作成する事にしてみました。

テンプレートファイルは以下のものを利用。

• CloudFormationテンプレート(YAML形式/VPC及びサブネットを作成)

パラメータは以下のものを利用。(テンプレート同様YAML形式で合わせたかったのですが--parametersでのYAMLファイル渡しは現状未だサポートされていない模様？(※参照URL)なのでJSONファイルで用意しました)

• CloudFormationパラメータファイル(JSON形式/VPC及びサブネットを作成)

テンプレート及びパラメータファイルを上記URLからそれぞれダウンロードし、aws cloudformation create-stackコマンドでスタック作成。

$ aws cloudformation create-stack \
  --stack-name vpc-and-subnets-for-glue \
  --template-body file:///Users/xxx/xxx/cfn-create-vpc-and-subnets.template.yaml \
  --parameters file:///Users/xxx/xxx/cfn-create-vpc-and-subnets.parameters.json
{
    "StackId": "arn:aws:cloudformation:us-east-1:XXXXXXXXXXXX:stack/vpc-and-subnets-for-glue/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
}

Public Subnetを2つ有するVPCが作成出来ました。

VPCエンドポイントの作成

VPCエンドポイントの作成対象となるVPCが作成出来ましたので、当ステップで必要となる実作業を行います。

• VPC エンドポイント - Amazon Virtual Private Cloud
• 【新機能】S3がVPCのプライベートサブネットからアクセス可能になりました！ ｜ Developers.IO

AWS管理コンソールのVPCメニューから[Endpoints]→[Create Endpoint]を押下。

VPCに上記で作成したVPCを選択、対象サービスにs3を選択し、ポリシーはフルアクセスとします。[Next Step]を押下。

対象となるルートテーブルを選択。ここは2つのPublic Subnetが紐付いている方を選択します。

VPCエンドポイント作成完了です。

JDBCデータストアに対する接続設定 (自己参照ルールを持つセキュリティグループの作成・設定)

AWS GlueコンポーネントがRedshiftやRDSのようなデータストアにアクセス出来るようにするには個別のセキュリティグループ設定が必要となります。

その設定とは、全てのTCPポートに対して自己参照のインバウンドルールを持つセキュリティグループを作成し、そのセキュリティグループを活用する...というものです。自己参照ルールを作成する事で、対象ソースを「VPC内の同じセキュリティグループを設定しているもの」に制限する事が出来ます。(※全てのネットワークに対して公開されている、という形にはなりません。VPCのデフォルトセキュリティグループには、既に全てのトラフィックの自己参照ルールが設定されている場合があります。

ドキュメントの該当箇所を読んでみると、Amazon Redshiftの場合もRDSの場合も同じセキュリティグループに対して設定を行っているようです。情報を整理してみると以下の様な感じになりますでしょうか。同じセキュリティグループを設定している事で、細かなアクセス制御をせずとも「このセキュリティグループを設定している要素からであればアクセスを全て許可する」という制御が実現出来る、という訳ですね。

実際に作成してみましょう。自己参照のルールのみを定義したセキュリティグループを作成し、必要な要素に割り当てる形を取りたいと思います。まずはガラだけ作成し、

自己参照ルールの設定をインバウンド・アウトバウントそれぞれに追加します。

追加するインバウンドルール：

Type	Protocol	Port Range	Destination
All TCP	TCP	0–65535	上記で作成した セキュリティグループのID

追加するアウトバウンドルール：

Type	Protocol	Port Range	Destination
All TCP	TCP	0–65535	上記で作成した セキュリティグループのID

Amazon Redshiftクラスタ作成の際は上記「自己参照ルール」を適用したセキュリティグループと、別途Redshiftアクセス用に新設したセキュリティグループの2つを割当てておきます。

上記セキュリティグループを割り当てた状態で作成したクラスタへのアクセス確認を試みてみます。この辺りは特に問題無さそうです。

$ psql -h xx.xx.xxx.xxx -U root -d cmredshiftdb -p 5439
Password for user root: 
psql (9.6.3, server 8.0.2)
SSL connection (protocol: TLSv1.2, cipher: ECDHE-RSA-AES256-GCM-SHA384, bits: 256, compression: on)
Type "help" for help.

# 

RDSインスタンスの設定についてもAmazon Redshiftと手順は同じです。今回のケースの場合であれば上記で作成したセキュリティグループをRDSインスタンス作成の際に紐付けて設定しておく事で連携が可能となります。

VPCのDNS設定

AWS Glueを利用する場合、VPCのDNS設定がDNSホスト名(enableDnsHostnames)及びDNS解決(enableDnsSupport)の値がいずれもtrue(有効)となっている必要があります。管理コンソールVPCメニューで所定のVPCの概要を開くか、

AWS CLIコマンド(aws ec2 describe-vpc-attribute)で個別に属性を指定する事で確認が可能です。

$ aws ec2 describe-vpc-attribute --vpc-id vpc-05372xxx --attribute enableDnsSupport
{
    "VpcId": "vpc-05372xxx", 
    "EnableDnsSupport": {
        "Value": true
    }
}
$ aws ec2 describe-vpc-attribute --vpc-id vpc-05372xxx --attribute enableDnsHostnames
{
    "VpcId": "vpc-05372xxx", 
    "EnableDnsHostnames": {
        "Value": true
    }
}

今回のケースでは新規にVPCを作成してすぐの状態なので上記の様にいずれもtrue(で変更無し)でしたが、必要に応じてコンソールメニューで変更してください。(注：Amazon Route 53を使用している場合、設定がDNSネットワーク属性を上書きしないことを確認してください。)

開発エンドポイント用の環境設定

AWS Glue上でETLスクリプトを実行する際、開発エンドポイントを使用してスクリプトを開発＆テストする事が出来ます。

AWS Glueが必要なリソースにアクセス出来るようにするために、サブネットルートテーブルに行を追加し、Amazon S3のプレフィックスリストをVPCエンドポイントに関連付けます。この「プレフィックスリストID」はVPCからのトラフィックがVPCエンドポイント経由でAWSの各種サービスにアクセスする事を許可する"アウトバウンドセキュリティグループルール"を作成するために必要となります。

この開発エンドポイントに関連付けられている「ノートブックサーバ」への接続をローカルマシンから簡単に行うためには、ルートテーブルに行を追加してインターネットゲートウェイIDを追加します。

• VPC エンドポイント - Amazon Virtual Private Cloud

対象となるVPCを選択し、ルートテーブルにVPCエンドポイントを追加...しようと思ったのですが、今回の手順の場合は既にこのタイミングでルートテーブルにエンドポイントの内容が設定されている状態でした。なのでこの手順は確認のみで次へ。

セキュリティグループの設定

AWS Glueがコンポーネント間で通信出来るようにするためには、全てのTCPポートに対して自己参照のインバウンドルールを持つセキュリティグループを指定します。この部分は前述の手順と同じですね。

こちらの手順もドキュメントを読んでみると、前述の手順と同じセキュリティグループIDでのスクリーンショット画像になっています。...という事は自己参照のインバウンドルールのアクセス制限を行わせるリソース、すなわちAWS Glue及びAWS Glueがアクセスする事になるリソースには全てこの自己参照ルール設定のセキュリティグループになる、という事なのでしょう(たぶん)。

ここまでの手順で出来上がった要素

当エントリではVPC及びサブネットを作成し、Amazon S3へのVPCエンドポイント経由でのアクセス設定を行いました。構成図的には以下のような形となります。(※画像は公式ドキュメントより拝借)

また、AWS Glueがアクセスする事になる各種AWSリソースに対して、「自己参照ルール」を適用させたセキュリティグループの作成・展開についても行いました。情報を整理すると以下の様になりますでしょうか。AWS Glueが必要とするアクセスは「自己参照ルール」を適用したセキュリティグループ同士であれば可能とする事が出来る様になるため、このような形を取っている...という理解です。

まとめ

という訳でAWS Glueの実践入門第2弾、VPC及びデータソース・リソース周りの環境設定を進めてみた内容のご紹介でした。これでAWS Glueの諸要素を実際に動かすための準備が出来た形となります。以後のエントリでは本丸である「AWS Glue」の機能や要素について実際に内容を見ていきながら機能を実践していきます。(以下のシリーズでその内容を纏めていく予定です)

• AWS Glue実践入門 ｜ シリーズ ｜ Developers.IO